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7. Program Library Details 


7.1. GENERAL 


The system program library files, which may be composed of program source, macro/JPROC source, object, and 
load modules, are created and used by the various components of the SPERRY UNIVAC Operating System/3 
(OS/3) during the normal course of system operation. It is these library files that the librarian services and 
maintains based on particular system needs and constraints determined by the user. 


For the system user to realize the full extent of the capabilities of the librarian, he must be aware of the organization 
and content of the program libraries in the system. Thus, the organization and content of the system program library 
are presented in this section of the manual. 


The user also may elect to establish a program library of his own. If so, the librarian also can be used to maintain 
— the object, program source, macro/JPROC source, and load code sets contained in this library, under the same 
guidelines it uses when servicing the system program library files. 


7.2. LIBRARY FILE LAYOUT 


The system library is composed of five permanent disk files and one temporary disk file for each job being 
processed in the system. All the files consist of at least a label, a single element, and an end-of-file marker; they 
are structured to support fixed-length block, variable-length record data and contain a directory partition. The 
directories are in fixed-length block, fixed-length record format. 


Each of the five permanent files are 3-partition SAT files. One partition is used to maintain a directory for the 
file, and the other two are used to store the program modules contained in the file. When these files are 
initialized by the librarian, the space allocated for each file is distributed as follows: 


s Two percent is allocated for the directory partition. 

s Forty-eight percent is allocated for the prime data partition. 

a No space is allocated for the second data partition. 

a Fifty percent of the space allocated to each file is initially unassigned. 


This initial allocation technique allows the librarian to assign file space to the various partitions in a file on an 
“as needed” basis, and thus prevents space from being allocated for a partition that may never be used. (At 
; present, only block load modules require the use of a third partition.) Thereafter, when a partition becomes full 
( wae and requires more space, the librarian extends the partition using some of the free space it has in reserve. Only 
the partition that was full is extended, and the amount of the extension is based on the file extension increment 
specified on the EXT job control statement used to create the file. When all the free space is allocated, the 
dynamic file expansion capability of the supervisor is called on to provide additional free space for the file in the 
same increments previously used to effect the file extensions performed by the librarian. 
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The job temporary library files are special files established by job control at the time jobs are input to the system 
for processing. These files are dynamic in nature, in that their size and structure are variable and they exist only 
until the job is terminated. 


Any programs or data that may be in these files are unrecoverable once their associated jobs have been 
terminated. 


In addition, it should be remembered that your files, excluding system files, may be sharable (depending on the 
FILELOCK parameter you specified during supervisor generation). See the system installation user 
guide/programmer reference, UP-8074 (current version). Because OS/3 allows multiple ‘‘writers’’ to 
concurrently access sharable files, these files could be destroyed in a multiprogramming environment. It is 
recommended therefore, that critical user files be prefixed by $LOKnn to prevent them from being accessed 
concurrently by multiple writer programs. 


Providing information needed to create new files or extending existing files on disks is the function of the EXT 
job control statement. See job control user guide, UP-8065 (current version) for details on this and other job 
control statements. 


7.2.1. Library Blocks 


Library blocks are fixed-length, 256-byte blocks (Figure 7—1). Each block is composed of a 5-byte block prefix 
and up to 251 bytes of variable-record data. The block prefix includes a 3-byte logical block number, a 1-byte 
value indicating a block length (not including the block prefix), and a 1-byte check sum reflecting an exclusive OR 
for relevant data. Records within the block are variable in length up to a maximum size of 251 bytes for any given 
record including the record prefix. 


BYTE 
NO. 


CONTENT 





BLOCK PREFIX 


BLOCK FIELD DESCRIPTIONS 


Byte 


oe Contents 
Position 


Biock number (bbb) Starting with 1 for the initial block, this is the logical block 
sequence number. 


Block length (bl) This is a binary value less than or equal to 251, indicating the 
number of bytes of relevant record data within the body of this 
block, not including the block prefix. 


Check sum (c) This is @ binary value reflecting an exclusive OR of all bytes 
in the block. 


Variable records (vr) Variable-length records comprising the body of data contained 
in this block 


Figure 7—1. Library Block Format 
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7.2.2. Library Records 








Library records are variable in length. Each record is composed of a 2-byte record prefix and up to 249 bytes of record 
data (Figure 7—2). The record prefix includes a length byte and a type byte. The type byte indicates the specific type of 
record that follows the record prefix. The length byte indicates the size of the respective record (not including the 
record prefix) up to a maximum of 249 bytes. 
' BYTE NO. 
CONTENT 
RECORD RECORD RECORD 
PREFIX PREFIX PREFIX 
RECORD FIELD DESCRIPTIONS 
Byte Contents 
Position 
Record length (rl) This is a binary value, less than or equal to 249, indicating the 
length of the respective record (not including the record prefix). 
Type (t) This is a type byte indicating the specific type of record. (Refer to 
Table 7—1.) 
mee” Variable-length Body of the particular record (up to 249 bytes each) 
record data (vr) 
Figure 7—2. Library Record Format 
7.2.3. Record Type Byte 
Associated with each record within a given library file is the type byte occurring in the respective record prefix. This 
byte is used to identify the record as to its code set and recordparticulars. A list of the record type byte values possible 
in an OS/3 system library file and their meanings is presented in Table 7—1. Note that the type byte field also exists 
in disk library directory items, as described in 7.4. 
Table 7—1. Record Type Byte Descriptions (Part 1 of 2} 
Type Byte Value D enue 
t 
(Hexadecimal) or reo 
Nullified item records 
TEXT/RLD records in object modules 
Transfer records in object modules 
Standard ENTRY records 
Standard EXTRN records 
— 


V-CON records 
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Table 7—1. Record Type Byte Descriptions (Part 2 of 2} 


(Hexadecimal) 
Named CSECT records 
Unnamed CSECT records 
Named common records 
Unnamed common records 
=e Object code ISD records 
TEXT/RLD recordsiin toad modules 
Transfer records in toad modules 
Load code ISD records 


<P Load code ISD records 


Program source or macro/JPROC source module records 


Compressed source code item 

Blocked text or RLD records 

Control statement records 

Object module header records 

Load module header/phase header records 
Beginning of group demarcator records 

EOF sentinel records 

Macro/JPROC name header records (in directory only) 
Macro/JPROC module header records 

Program source module header records 

End of group demarcator records 

Blocked load module header/phase header records 
Shared code ENTRY (SENTRY) records 

Shared code EXTRN (SEXTRN) records 


Resource records 





7.3. CODE SET COMPONENTS 


Code set components are defined as those records that, when combined in a particular sequence, make up @ 
program source module, a macro/JPROC source module, an object module, a load module, or a grouped code set 
module. The elements, or records, comprising these code sets are listed, as follows, by module type (in 
hexadecimal) and are described in detail in 7.3.1 through 7.3.4. 
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A. GROUPED CODE SETS 
1 beginning of group demarcator, type AO 
Separate or mixed sets of source, macro/JPROC, object, or load modules 
1 end of group demarcator, type A8 
1 EOF code sentinel, type A1 
B. PROGRAM SOURCE AND MACRO/JPROC SOURCE MODULE CODE SETS 


1 header, type A3 or A4 
1 or more source items, type 24 or 25 


C. OBJECT CODE SETS 


1 header, type 80 

1 or more linkage editor control statements, type 40 (optional) 

1 or more CSECT, types 08, 09, OA, OB 

1 or more ESD, types 04, 06, 07 (optional) 

1 or more text, type 02 

1 transfer, type 03 

1 or more linkage editor control statements, type 40 (optional) 

1 or more [SD records, type OC ~<~ 


D. LOAD CODE SETS 


header, type 90 or BO (root phase definition) 

or more SENTRY, type C4 (optional) 

or more sets of resource and SEXTERN records, type C8 and C6 (optional) 

or more text, type 12 or 32 

transfer, type 13 

or more sets phase definition (type 90 or BO), text (type 12 or 32), and transfer (type 13) records, 
depending on the number of phases in the load module (optional) 

1 or more !SD records, type 1C =< 


ee ee ee ee ee 


7.3.1. Grouped Code Sets 


Library files may contain group demarcators that divide different sets of elements into specific groups. Groups may 
be composed of any one code set type or may be a mixture of all sets in any order. The grouping is strictly optional and 
can be performed by the librarian at the user’s option. The librarian can manipulate code within libraries on a group 
basis and these files may then, in turn, be accessed by processing routines at a group level. Groups may overlap other 
groups and may be nested to any level. (Figure 7—3 illustrates the nesting of groups.) Beginning and end of group 
(BOG and EOG) records (type AO and AB, respectively) demarcate and name the grouped code sets. The library items 
peculiar to grouped code sets are described in Tables 7—2 through 7—4. 
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GROUP( GROUP] C SET 
NEST NEST GROUP\ SET 
A B NEST EOG 
D SET 

SET 

EOG 

SET 

EOG 


SET 11 


1 
2 
3 
B 
4 
Cc 
5 
NEST BOG D 
6 
7 
Cc 
8 
9 
D 
1 


aan) 


teeter 


NOTE: 
All sets are contained within Group Nest A. Some sets are subnested and overlapped as follows: 


A. Sets 6, 7, 8, and 9 are contained within Group Nest D, which is contained within Group Nest B, which is contained within 
Group Nest A. Group Nest C and Group Nest D overlap within Group Nest B. 


B. Sets 5, 6, and 7 are contained within Group Nest C, which is contained within Group Nest B, which is contained within Group 
Nest A. 


C. Sets 4 through 10 are contained within Group Nest B, which is contained within Group Nest A. 
D. Sets 1, 2, 3, and 11 are contained only within Group Nest A. 


Figure 7—3. Example of Nested Group Code Sets 


Table 7—2. Beginning of Group (BOG) Header Record Format 


Byte Contents 
Position 
Length prefix 38 (binary format) 
Type prefix Adrs6 


Group name Symbolic name of the logical group of code sets contained within this 
group and terminated by this record (left-justified and space-fitied) 


Comments Up to 30 bytes of pertinent comments (as deemed necessary to identify 
the group) 
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Table 7—3. End of Group (EOG) Trailer Record Format 


Byte 
Position 


Length prefix 


‘ Type prefix 


Group name 


Table 7—4. 


Byte 
Position 
Length prefix 
Type prefix 
Unused 


Name 


7.3.2. Source Module Code Sets 


Contents 


8 (binary format) 
ABs 


Symbolic name of the logical group of code sets contained within this 
group and terminated by this record (left-justified and space-filled) 





End of File (EOF) Sentinel Record Format 


20 (binary format) 
Alie 
00,6 


ENDLIBAA 





Source module code sets within library files may be composed of any type of source module statements from 
BAL macro definitions or own-code specifications up through specific language processor parameters and 
JPROC’s written in job control language. The library items peculiar to source code sets are described in Tables 


7—5, 7—6, and 7—7. 


Table 7—5. Source Module Code Header Record Format (Part 1 of 2) 


Byte 
Position 
Length prefix 
Type prefix 
Unused 
Flags 
Unused 


Module name 


56 (binary format) 

A3,, or Adis 

00,, 

00,., or 80, if module has been corrected 


004, 


Symbolic name of the source code set originated by this record 
{left-justified and space-filled) 
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Table 7—5. Source Module Code Header Record Format (Part 2 of 2} 


Byte Contents 
Position 


Date In the form as it appears in the preamble 


Time In the form: hour-minute (packed decimal less zone fieid) 


Unused 0016 


Comments Up to 30 bytes of pertinent comments as deemed necessary to 
identify the source module. 





Table 7—6. Source Module Code Statement Record Format 


Byte Contents 
Position 


Length prefix Variable; 2+ length 
Type prefix 2416 


Source record Source statement 





Table 7—7. Compressed Source Module Code Statement Record Format 


Byte Contents 
Position 


Length prefix Variable; 2+ compressed source length 


Type prefix 2516 


Source record Compressed source statement 





7.3.3. Object Code Sets 


Object code within library files is composed mostly of text and relocation data generated as output of the various 
language processors. This code exists in a format acceptable to the linkage editor and contains additional record 
types used by the linkage editor for load module generation. Object module records are variable in length and are 
packed as densely as possible within a given library block. The desired order of appearance of all records within an 
object code set is: 


Object module header record 


Control statement records* 


*Contro/ statement records are generated by certain language processors and may be used to designate control information 
necessary to a subsequent linkage editor run. 
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All control section records (must precede associated text and entry ESDs) 


All ESD records (names must be unique) 


* All ISD records 
All text/RLD records 
Object module transfer record 


Control statement records 


These records are described in Tables 7—8 through 7-17; 


Table 7—8. Object Code Header Record Format 


Byte 
Position 
Length prefix 
Type prefix 
ESID 
Unused 


Fiag 


Address 
Module length 


Module name 


Date 
Time 
Unused 


Comments 


55 (binary format) 
80,6 


001, 


Bit 0 $et to indicate that the module has been patched 
Bits 1-6 Not used 
‘Bit 7 Set to indicate that the object module is reentrant 


Assembled or compiled origin of the object module 
Total number of bytes required for the object module 


Symbolic name of the object module originated by this record 
(left-justified and space-filled) 


In the form as it appears in the preamble 
Hour-minute (packed decimal less zone field) 
00:6 


Up to 30 byes of pertinent comments as deemed necessary to identify 
the object module 





ISD records are also generated by certain language processors and are used by JOBDUMP to produce a formatted dump if an 


abnormal termination occurs in your load module. 


<~_ 
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Table 7—9. Object Code Control Section Record Format 


Byte Contents 
Position 


Length prefix 19 (binary format) 


Type prefix 08,6, 0915. OA;,, or OB,. (See Table 7—10.) 


ESID External symbol identification assigned to this control or common 
section 


Flag bytes 8000,, indicates a deferred length specified in the transfer record 
of this object module; ignore bytes 9—12 


Section address Compiled address of the start of this control or common section 
Section size Total length in bytes of this contro! or common section 


Section name Symbolic name of the control or common section (left-justified and 
space-filled) 








Table 7—10. Possible Control Section Record Types 


Type of Control Section 


Named control section Address 


Unnamed control section Ee i). aeea Blanks (40,,) 





Blanks (40,,) 


Unnamed common section 








Table 7—11. Object Code ESD Record Format 


Byte 
Position 
Length prefix 15 (binary format) 
Type prefix 0446, 0616, or O716 (See Table 7—12.,) 
ESID External symbol identification assigned to this ESD reference 


Unused OOr.6 


Relative address Processor-generated address or value assigned to this ESD reference 


ESD name Symbolic name of the ESD reference 
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Length prefix 
Type prefix 
ESID 


Flag 


Flag 
Compile origin 


Attributes 
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Table 7—12. Possible ESD Record Types 
Type Length 
Se 
Penn | 
[ven [| 


Field Contents 


Variable 

Ocig 

External symbol identification of CSECT assigned to the ISD 
Bits O—1 unused 

Bit 2 set to indicate Type 3 ISD 

Bit 3 set to indicate Type 4 ISD (comment) 

Bits 4—7 unused 

Unused 


Processor generated address assigned to this {SD 


Symbolic name and attributes of the ISD item 
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Table 7—14. Object Code Text/RLD Record Format 


Byte 
Position 


Length prefix 


Type prefix 


ESID 


Text length 


RLD length 


Flag 


Relative address 


9—9+ Text data 
Text iength 


9+ text length RLD data 
+ RLD length 

backward thru 

9 + text length 


NOTES: 





Byte 
Position 


ESID 


Flag 


Address 


Variable: 7 + text length + RLD length (binary format) 
0216 


External symbol identification with which the text data in this record 
is associated. 


Number of bytes less one byte of text data in this record 


Number of bytes of relocation data in this record (a multiple of three 
bytes) 


01,6 if patched text item 


Processor-assigned relative address of first byte of text data in this 
record 


Instructions and/or data generated by a processor and relative to the 
ESID specified 


Three byte relocation masks used to modify the various fields of 
preceding text data in this record (See Table 7—15.) 


Table 7—15. Relocation Mask Formats 


Contents 


External symbol! identification of the external reference whose 
subsequent value will be used to modify the addressed field 


Designator byte reflecting type, size, and position of the 
modification field (Figure 7—4) 


Relative record pointer indicating the most significant (leftmost) 
byte of text data at which the modification is to begin (first text 
byte, 0; 2nd byte, 1, etc.) 





1. Each RLD data field in a given text record is composed of three bytes of relocation information designating the field size, field 
position, and associated external index relevant to the modification of the addressed data bytes in this text record. The field 
may be positively or negatively relocated at link edit time and can be modified by one or more relocation masks. The text and 
its associated relocation masks always must appear within the same logical record. 


2. Load module relocation masks are identical, except that the ESID field represents the phase number assigned to the 
definition referenced by the address constant in the linked toad module. 
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Address (in hexadecimal) pointing to the leftmost byte 
of the field to be modified. The position is relative to 
the first byte of text in the record (0 refers to the 1st 
byte, 1 to 2nd, etc.) 





ESID: The ES!D referring to the ESD entry in the input module 
on whose value the relocatable data depends. 
!f a load module RLD, this byte reflects the phase number of 
the phase supplying the definition for this reference. 


Figure 7—4. Relocation Mask Field 


This 5-bit field indicates the 
number of bits to be modified. 
This number is one less than 
the actual number of bits 

used (0-31). The 7-, 15-, 23-, 
and 31-bit modifications 

may apply only to load 
module RLOD. 


0 - Rightmost bit of the modification 
field is on a byte boundary. (Always 
0 for load module RLDs). 


1 - Rightmost bit of the modification 
field is on a half-byte (hexadecimal) 
boundary. 


1 - V-type address constants 
0 - Others (always O for load 
module RLDs) 


Type of relocation 
0 - Addition (+) 
1- Subtraction (-) 


PAGE 


7= 


13 
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Table 7—16. Object Code Transfer Record Format 


Byte 
Position 


Length prefix 11+ RLD (binary format) 


Type prefix 0316 
ESID Externa! symbol identification assigned to the transfer reference 
Text length 3 (binary format) 


RLD iength Number of bytes of relocation data in this record (a multiple of 3 
bytes) 


Flag 80,, if deferred length is present in bytes 6—8 


40,, if the transfer record does not terminate the object 
module (1 orf more control statements follow) 


Deferred length One CSECT or common Section (named, unnamed, or blank) may have 
its respective record flagged to indicate that the object module 
transfer record specifies the actual! length 


9—12 Transfer address Processor-generated object module transfer address 


13—13 + RLD RLD data Relocation data used to modify the transfer address 
fength 





Table 7—17. Object Code Control Statement Record Format 


Byte 
Position 


Length prefix 80 (binary format) 


Type prefix 40,5 


Control statement Source contro! statement 





NOTE: 


Any control statements appearing in an object module must directly follow a header record or directly follow a transfer record. 
The latter case is indicated by the appropriate setting of the flag byte in the transfer record. 
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7.3.4. Load Code Sets 


Nee” 
Load modules are produced by the linkage editor and are loaded in the system at program execution time by the 
system load facility. Load programs may be composed of more than one phase or program segment. The initial phase 
is called the root phase. The composition of each phase of a load program is: 
s a phase definition record; 
® one or more SENTRY records (optional); 
s one or more resource records (optional); 
s one or more SEXTRN records (optional); 
s one or more ISD records (optional); <q 
s one or more text/RLD records: and 
td] a transfer record. 
All load programs (segmented or not) contain root phases. If the automatic overlay mechanism is used, standard text 
records reflecting that facility are generated into the root phase. (Automatically included modules also become 
resident in the root phase.) Each phase segment contains its own transfer record signaling termination of the phase 
and a possible start of execution address. The load code set records are described in Table 7—18 through 7—22. 
Table 7—18. Load Code Phase Definition Record Format (Part 1 of 2) 
— 
Byte 
Position 
Length prefix 67 (binary format) 
Type prefix 90,, 
Phase number Linkage editor assigned phase number of this phase 
Flag Byte 3 
Bit O Set in root phase header to indicate clear module 
partition as defined in bytes 27—30 
Bit 1 Set to indicate that the load module calls reentrant 
code 
Bit 2 Set to identify the load module as reentrant 
Bits 3-7 Not used 
Byte 4 
Bit 0 Set to indicate that module has been patched 
Bits 1-7 Not used 
Phase toad address Linkage editor assigned relative origin of this phase 
Phase length Total number of bytes required for this phase segment; value represents 
the highest zero relative address assigned to this phase 
Phase name Symbolic name assigned to this loadable phase segment 
Date Month-day-year (packed decimal! fess zone field) 
— 


Time Hour-minute (packed decimal less zone field) 
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Table 7—18. Load Code Phase Definition Record Format (Part 2 of 2) 


SENTRY count 


Module length 


Alias phase name 


Comments 


Length prefix 


Type prefix 


Number 





Length prefix 


Number of SENTRY records contained in the load module 


Tota! number of bytes required for loading the module; value 
represents the highest zero relative address assigned to the load 
module 


Symbolic name assigned to this loadable phase segment by the 
linkage editor OVERLAY or REGION controi statement that created 
the phase 


Up to 30 bytes of pertinent comments as deemed necessary to 
identify the load module segment 





Table 7—19. Load Module Shared Code Record Formats 


15 (binary format) 15 (binary format} 15 (binary format) 


C8, C656 C416 


SENTRY 
number 


SINDEX 
number 


Resource 
number 


Link 
address 


Resource Byte 5 has resource number 
size Bytes 6—8 unused 


SENTRY name left- 
justified and 
blank-filled 


SEXTRN name left- 
justified and 
blank-filled 


Resource name 
left-justified, 
and zero-filled 


Table 7—20. Load Code ISD Record Format (Part 1 of 2) 


Contents 


Variable 


Type prefix 1c 


Phase number 


Flag 


Flag 


Link origin 





Linkage editor assigned phase number of this phase 


Bit O set to indicate Type 1 {SD (CSECT) 
Bit 1 set to indicate Type 2 ISD (comment) 
Bit 2 set to indicate Type 3 ISD 

Bit 3 set to indicate Type 4 ISD (comment) 
Bits 4—7 unused 


Unused 


Linkage editor assigned relative origin for this ISD record 
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Table 7—20. Load Code ISD Record Format (Part 2 of 2) 


9—12 Compile origin 
Size 


Attributes 


Table 7—21. 


Length prefix 
Type prefix 
Phase number 
Text length 


RLD length 


Flag 


Load address 


9—9+ text length Text data 


9 + text length + RLD RLD data 
length backward thru 
9 + text length 


Byte Contents 
Position 


Language processor generated address to the ISD record 









Size of this ISD record 


Symbolic name and attributes of this ISD record 


Load Code Text/RLD Record Format 


Variable: 7 + text length + RLD length (binary format) 


T2y6 


Linkage editor assigned phase number of text data in this record 


Number of bytes less 1 of text data in this record 


Number of bytes of relocation data in this record (a multiple of 3 
bytes) 


01,, if a patched text item 


Linkage editor assigned phase segment load address assigned to the 
first byte of text data in this record 


Instructions or data to be loaded relative to the load address 


Three byte relocation masks used to modify text in the record 
(Table 7—15) 


Table 7—22. Load Code Transfer Record Format 


Byte 
Position 
Length prefix 
Type prefix 
Phase number 
Text length 


RLD length 


— 5—8 Unused 


9—12 ’ Transfer address 


13—13 + RLD length RLD data 





Comments 


11 + RLD data length (binary format) 

13:6 

Linkage editor assigned phase number of this phase 
3 (binary format) 


Number of bytes of relocation data in this record (a multiple of 3 


bytes) 
0:6 
Linkage editor assigned phase segment transfer address 


Relocation data used to modify the transfer address 





8062 Rev. 5 
UP-NUMBER 


7.3.5. Block Load Code Sets 


SPERRY UNIVAC Operating System/3 





UPDATE LEVEL 


PAGE 


Unlike the standard load module, which has data in two partitions, the block load module has data in three 
partitions. The data in partitions one and two are similar to the standard load module data in that they are 
structured as index and data partitions. However, the data in partition three is not structured and is made up of 
contiguous text data, free of any contro! information. In other words, partition three is made up of the actual 
block module text records. The data in partition two describes the boundaries of each phase in partition three. 
The block module text data (partition three) is in sequential load order and is binary zero-filled when appropriate. 


The order of all modules within the block load code set is shown in Tables 7—23 through 7—28. 





Byte 
Position 
O—7 


Table 7—23. Partition One—Directory Entry 





Symbolic name 


Type flag (BO;,) 









Block relative pointer 


Record relative pointer 





Table 7—24. Partition Two — Block Load Module Header Record (Part 1 of 2) 


Byte 
Position 


Length prefix 


Type prefix 


Phase number 


Flag 


Flag 


Phase toad 
address 


Phase length 


Contents 


75 (binary format) 


BO\, 


Linkage editor assigned phase number of this phase 


80,. indicates clear module partition as defined in bytes 27—30. 
40,, indicates that this module calls shared code. 
20,, indicates that this is a shared load module. 


80,, indicates this module has been patched. 


Linkage editor assigned relative origin of this phase 


Total number of bytes required for this phase segment: value 


represents the highest relative zero address assigned to this phase. 
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Table 7—24. Partition Two — Block Load Module Header Record {Part 2 of 2) 


Phase name 


Date 


Time 


SENTRYs 


Module length 


Alias phase name 


Comments 


Block number 


Block number 


Displacement 


Checksum 





Symbolic name assigned to this loadable phase segment 


In the form as it appears in the preamble 


Hour-minute (packed decimal less zone field) 


Number of SENTRYs recorded 


Total number of bytes required for loading the module; vaiue 
represents the highest relative zero address assigned to the load 
module. 


Symbolic name assigned to this loadable phase segment by the 
linkage editor OVERLAY or REGION control statement that created 
the phase 


Up to 30 bytes of pertinent comments as deemed necessary to 
identify the joad module segment 


Pointer to text block (beginning of this phase in partition 
three) 


Pointer to first text or transfer block of this phase in partition 
two 


Pointer to first text or transfer record of this phase in partition 
two 


XOR of first byte of each text block of partition three 
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Table 7—25. Partition Two — Block Load Module RLD Record 


Byte 


Ae Contents 
Position 


Length prefix 1+ no. of RLO times 5 (binary format) 


Type prefix 3216 


Length of RLDs Number of RLD masks times 5 


3(3 + nx 5—1) RLD masks 5 byte RLD masks (see Table 7—-26) 





Table 7—26. RLD Mask 


Byte 
Position 


Phase number (in load module RLD mask) 


Bits (in load module RLD masks) 


Load module relative address 
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Table 7—27. Partition Two — Block Load Modules Nonphase Text/RLD Record 


ae 
Pye Comments 
Position 
Length prefix Variable: 7 + text length + RLD length (binary format) 
Type prefix 1216 
Phase number Linkage editor assigned phase number of text data in this record 
Text length Number of bytes less 1 of text data in this record 
RLD length Number of bytes of relocation data in this record (a multiple of 3 
bytes) 
Flag O1,. tf a patched text item 
Load address Linkage editor assigned phase segment load address assigned to the 
first byte of text data in this record 
9—9 + text Text data Instructions and/or data to be loaded relative to the load address 
length : 


9 + text RLD data Three byte relocation masks used to modify text in the record (Table 
length + 7—15) 

RLD tength 

backward 

thru 9 + 

text length 





NOTE: 


Nonphase text records are present in block load modules when text/RLD items are detected that are not part of a given phase. 
Such text/RLD items outside the phase being loaded are to be loaded at the same time. 
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Table 7—28. Partition Two — Block Load Module Transfer Record 


Byte 
Position 


Length prefix 11 + RLD data length (binary format} 


Type prefix 1346 


Phase number Linkage editor assigned phase number of this phase 


Text length 3 (binary format) 


RLD length Number of bytes of relocation data in this record (a multiple of 
3 bytes) 


5—8 Unused 00, 


9—12 Transfer address Linkage editor assigned phase segment transfer address 


13—13 + RLD RLD data Relocation data used to modify the transfer address 
length 





7.4. DISK LIBRARY DIRECTORIES 

Library files existing on disk are supplemented with a disk file directory composed of 13-byte records, each of 
which points to a specific demarcation record in the file. The directory precludes the need for scanning the 
library file to obtain a needed record. instead, directory scanning suffices until the program is located. The 
pointers existing within the directory explicitly designate the position of the required element within the library 
file data partition. The format of the library file disk directories exists as a function of the needs of the prime 
routines accessing the directories. The directory format differs in record layout from the prime data partition of a 
library file, in that directory records are fixed, 13-byte blocked items. The directory block prefixes are identical to 
those of the file partition. 

Disk directory records are composed of: 

a a name field; 

s a type indication; and 

s a file pointer 

Directory entries are made whenever the respective file record is: 

s a module header for program source, macro/JPROC, or object code; 

s a phase definition for each phase of a load module; 


a an entry ESD record for object code; 


s a beginning-of-group (BOG) or end-of-group (EOG) demarcator. 
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s a named CSECT record for object code; or 


a a procedure name for a macro module in proc format. (This is the directory entry for which there is not a 
unique corresponding record in the prime data partition. This item points to the module header record.) 


7.4.1. Directory Format 


' System libraries are built and managed by using the system access technique (SAT) access method. Thus, the first 
partition of each standard library file in the system consists of an index of pointers to the prime data area of the file 
described by the second partition. This directory index consists of a series of 13-byte slots, each pointing to the 
corresponding record in the prime data area. The directory blocks may be 251 bytes in length; the last four bytes of 
each directory block are unused when the block is full (contains 19 items). As many directory blocks as are needed to 
accommodate the needed number of index entries for a given library are available. The last index entry for each 
library directory is the index to the EOF record in the prime data partition. Figure 7—-5 illustrates the disk library 
file structure and the format of each directory record. 


PRIME DATA 
INDEX PARTITION DIRECTORY RECORD PARTITION 



























3-BYTE 1-BYTE 









8-BYTE 


BLOCK RECORD 
rae RELATIVE RELATIVE 
POINTER POINTER 


DIRECTORY 
BLOCK 


DIRECTORY 
BLOCK 


DIRECTORY 
BLOCK 





Figure 7—5. Disk Library File Structure 


The symbolic name field (bytes 1 through 8) of a directory record is used as the identifier of the module or demarcator 
existing in the prime data partition. The type field specifies the demarcation flag for the respective record. The values 
of the type flag field correspond to the record type field in the prime data area. The type flags possible in an index item 
are listed in Table 7—29. 
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Table 7—29. Disk Directory Index Type Flags 


Hexadecimal Value Demarcation 


Nullified item 


: ENTRY name (object module)* 


CSECT name (object module)* 


Object module header 


Phase header (load module) 


Beginning of group demarcator 


EOF sentinel 


Macro/JPROC name header 


Macro/JPROC module header 


Program source module header 


End of group demarcator 


Block module header record 





*Multiple duplicate names can appear in a library file directory. 


The block relative pointer to the prime data area is a relative block number within the second file partition 
indicating the block containing the respective record. The record relative pointer is the number of bytes from the 
beginning of the block to the beginning of the record. The record relative pointer and block relative number are 
computed when the prime data area is constructed. The pointers for macro name header index items (in the proc 
format) always point to the beginning of the proc module regardless of where the name directive is contained 
within the body of the module. 


7.5. CARD LIBRARIES 


The Jibrarian can punch libraries into cards and, in turn, access card files are input. Source module items, 
element headers, phase definitions, CSECT, ESD, ISD, PHASE, and TRANSFER records are punched directly. 
Text/RLD records in object and load elements are treated specially since the record size is variable. Thus, 
punched card formats for text/RLD records may require multiple punched card records. 


sane a a Sh A Ae a, SE RN RR RR A ma A a 
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Whenever object or load modules are punched into cards, a 5-digit sequence number is punched in columns 1 
through 5, providing a card deck sequence check facility. When punching source modules, the librarian creates 80- 
byte source records (the source module header is eliminated) directly from the library. 


When librarian functions require punched card output, the name PUNCH must be specified on the LFD job control 
statement. With the punched card output, the librarian creates an ELE card to precede the module and an EOD card t 
to end the module. The ELE card will be in the format: 







A OPERATION A OPERAND 


D1, module type, module name 





{ 


When filing object or load module card libraries, the librarian reconstructs the module from the card decks, checking 
the sequence number of each card and the record types within each module. When source modules are created from 
cards, the appropriate headers are created, prefixes attached, etc. 


7.6. TAPE LIBRARIES 


The formats for tape libraries are the same as those for disk libraries except that: 
a tape libraries have only a data partition, no directory partition; and 


s modules having the same name and type may exist in the same tape library. However, the first module 
{ ~~ encountered is the one processed. 


Because of the structure of a tape library, once a module is written to a library, that module cannot be deleted or 
altered in any way in that same library. Therefore, the input library and a new output library must be specified 
when making changes to a tape library. This new library can be another tape, disk pack or punched cards. The 
following control statements are not Supported for a tape library because the operation takes place in the input 
file: BLK, DEL, PAC, REC, REN, and REPRO. 


Your tape libraries must have the standard header and trailer label records and the name specified in the LBL job 
control statement must agree with the file header 2 label of your tape library. The data management user guide, 
UP-8068 (current version) provides the information concerning the header and trailer label records associated 
with tape libraries. ‘ 


All tapes can be prepped using either the prep option of the VOL job contro! statement or through the tape prep 
routine (TPREP, Section 9). 
7.7. DISKETTE LIBRARIES 


The librarian can either be input from a diskette, or punch to a diskette. Diskette library processing is the same 
as card library processing (7.5.). 


JIS F PRINT AN ERKRUK MESSAGEK AND TERMINATE KOEADING FUR THIS LIBRARY. 











; 516 # 
2440 OKA S17 GETSPACE LoS yNEXTSPAC = START OF AVAILABLE SPACE = 
‘JO00- 00009 518 INCRSPAC LA 1S,0U9,15 - END OF DESIRED ENTRY 
24 a4 OO4AL 539 Cc 15,ATABEND - IS THERE ROOM? 
2376 00376 §20 BH ~~ CVERFLOW NO 
24A0 O04AO 521 ST 15 sNEXTSPAC UPDATE NEXT SPACE POINTER 

$22 BR 14 ExIt 
2549 A78F GO549 OO7B8E S23 AVERFLOW MVC  LINEC39}5=CL39*#889 MEMORY OVERFLOW - INPUT TERMINATED*® 
"229 ““0029C S24 "BAL «UG PRINT PRINT ERROR MESSAGE 
2230 00230 525 B PRNTXREF START XREF IMMEDIATELY 

526 3 











527 8 LIBRARY FILE GET ROUTINE 
§28 * THE CURRENT RECORO, IF A SOURCE RECORD, WILL BE PROPERLY EXPANDED 
529 * INTO “CARD” - CTHERWISE JT WILL BE LGADED INTO “CARD” AS IS. 





“S30 8 IN EITHER CASE, THE RECORD TYPE CODE WILL BE PLACED INTO “RECTYPE*. 
521 @ IF THE RECGRD IS AN EOF SENTINEL, THIS ROUTINE WILL BRANCH 
532 * DIRECTLY TC “PRNIXREF". 


























































‘ 523 #@ 
Z24AC OC4AC 534 GETS st 14 ,SAVE14 SAVE RETURN ADORESS 
249E OG4SB 525 t 15 98P SOURCE CURRENT POSITION IN BLOCK 
e2bsa oT n—n"Oo7msR S36. ~~ ~©~)©6©6C)™©™~™~C RS yp SACTOLIBINGSD) =~ —SdSSTART OF A NEW BLOCK? 
2384 00384 537 BH GETSREC NO 
536 wAITF LIBIN WAIT FOR COMPLETION OF READ 
S44 SR Jo] 
289F OO8SF 545 1c 3} ,TOLIRINGS BLOCK LENGTH 
232A) O0gA} 546 LA },IOLIBIN®S(}) ; 
SiR AB TP ER TTA ENO BE BLOCK 
2498 00458 548 L 15.8P SOURCE RESTORE REGISTER 15 o” 
26E0 FOO! OO6ED 00001 589 GETSREC MVC RECTYPE 1t15) RECORD TYPE CODE 
24FS OO4F 8 550 “VI CARD.C® * CLEAR RECORD IMAGE AREA 
24fS 246-8 OG4FS OO4FS 551 MVC CARD#1(79)_CARD 
552 SR ie] “ 7 
EOOO TT 0000 Ss den ee nsa oo RE RENT fees 
FaO2 0000? S54 LA 1592t.1S53 SKIP OVER RECORD PREF Ix 
5§5 LTR 1,51 IS RECORD LENGTH Z2ERG? 
Zaz 108 GSE BZ “GETSNEXT YES - THERE *S NOTHING TO MOVE 
24FR OO4FS3 557 LA 14,CARD R14 SCANS CARD IMAGE 
26FP OCOED 553 cul RECTYPE sx *25* COMPRESSED SOURCE RECORD? 
a 2 OO3FC 559 - BE GETSCOMP ee WES - USE SPECIAL ROUTINE 
\ew” 
CROSS-REFERENCE UTILITY PAGE a 
¥ CODE ADDR1 ADOR2 LINE SOURCE STATEMENT : “‘OS/3 ASM T7/12/1: 
.560 BCTR 1,6 : OECREMENT FOR EXECUTE 
23F6 _003F6 561 Ex 1 ,GETSMOVE LOAD RECORD IMAGE a&S IS 
FOO] 0000} S562 LA 15311915} INCREMENT BLOCK POINTER 
26ED OG6ED 563 CLI RECTYPE gX*AR® ENO OF FILE SENTINEL? 
2426 0426 S68 tatoo ee BNE GE USN ENT one INO hs 
2230 00230 565 B PRNTXREF START PRINTING CROSS-REFERENCE 
E000 F000 00000 00000 566 GETSMOVE MVC 010,343,08153 EXECUTED TO MOVE PART OF RECORD 
S567 * EXPANSION ROUTINE FOR COMPRESSED SOURCE RECORDS 
568 GETSCOMP LR 0-15 CURRENT POSITION IN BLOCK 
569 AR O,! ADD RECORO LENGTH 
2488 00488 570 _ ST sO sWORK THE RECORD ENOS HERE. cn Boe = 
FOO! 00001 571 GETSCMPL IC Telte1S3 NUMBER OF BLANKS 
' $72 AR 14,2 INCREMENT CARD IMAGE POINTER 
FOOO 00000 573 Ic 1.0%,15) LENGTH OF FOLLOWING FEXT 
F002 00002 574 tA 3§,2¢,153 SKIP OVER CONTROL FIELO 
23F6 003F6 575 EX 1 »GETSMOVE MOVE FOLLOWING TEXT 
E00! 0000) S76 LA B9,101514) INCREMENT CARO IMAGE POINTER ee 
FOO] 00001 S77 ta 1551t1,15) INCREMENT BLOCK POINTER : 
2488 00488 578 Cc 15, WORK END OF COMPRESSED RECORD? 
24904 00404 579 BL GETSCMPL - NO - CHECK FOR MORE 
2898 00458 S80 GETSNEXT ST 15 »BP SOURCE UPDATE BLOCK POINTER 
24 a8 OO4AS 581 c 15 »BLOCKEND ENO OF BLOCK? 
244A OOS4A 582 BL GETS* NO - EXIT ae 
a oe Se oe) aS ta ee aah t, ~ GET  CYBIN,LIBINZ START READING THE NEXT “BLOCK” va as 
2498 2758 00898 00758 590 AVC BPSOURCE s=ATIOLIBIN®S3 RESET BLOCK POINTER 
249A Oo4aAac $91 GETSX L 29,SAVE148 RESTORE RETURN ADDRESS 
. 552 BR 14 Ex1T 
wow” 593 * 
; 594 # 1/0 ERRGR ROUTINES = 
| 95% eee nce t 
2548S 2785 00589 OO7BS 596 ERLIBIN MVC LINEt23)e=CL23°%*e8e LIBIN I/C ERROR aT® 
2458 00488 5ST ST 34 ,uQRK 
















6 48s 005¢1 00888 593 UNP K INE*24073 ,WORKESD 
2561 25€N 00561 OOSED 599 TR LINES 28( 6? ,HXTR-x FOP 


2567 ei 00567 OOa7CC 600 MVC LINE*3O0C1 7) ,=CL179* — STATUS BYTES =e fi: 
579 O0d22 6OL "WNP K LINE TASTS),LIGING SOUS) 
2579 BcEe 00579 OOSED 602 TR “LINE*SS USD LHXTR-x FOF ‘ s ee 


